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Abstract 

Complex  security  protocols  require  a  formal  approach  to  ensure  their  correctness.  The  protocols  are  fre¬ 
quently  composed  of  several  smaller,  simpler  components.  We  would  like  to  take  advantage  of  the  com¬ 
positional  nature  of  such  protocols  to  split  the  large  verification  task  into  separate  and  more  manageable 
pieces. 

Various  formalisms  have  been  used  successfully  for  reasoning  about  large  protocol  compositions  by  hand. 
However,  hand  proofs  are  prone  to  error.  Automated  proof  systems  can  help  make  the  proofs  more  rig¬ 
orous.  The  goal  of  our  work  is  to  develop  an  automated  proof  environment  for  compositional  reasoning 
about  systems.  This  environment  would  combine  the  power  of  compositional  reasoning  with  the  rigor  of 
mechanically-checked  proofs.  The  hope  is  that  the  resulting  system  would  be  useful  in  verification  of  secu¬ 
rity  protocols  of  real-life  size  and  complexity. 

Toward  this  goal,  we  present  results  of  a  case  study  in  compositional  verification  of  a  private  communication 
protocol  with  the  aid  of  automated  proof  tool  Isabelle/IOA. 
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1  Introduction 


Today’s  security  protocols  require  a  formal  approach  to  ensure  that  they  satisfy  important  correctness 
properties.  Traditional  ways  of  verifying  correctness  by  hand  are  prone  to  error  and  require  a  large  investment 
of  human  effort  and  patience.  Furthermore,  these  problems  tend  to  grow  worse  as  the  size  and  complexity 
of  the  system  being  verified  both  increase.  Automated  proof  tools  can  help  make  the  proofs  more  rigorous. 
Such  tools  also  need  a  lot  of  human  guidance,  and  the  automation  they  do  provide  typically  does  not  scale 
well  with  the  size  of  the  problem. 

The  protocols  we  are  interested  in  are  frequently  composed  of  several  smaller,  simpler  protocols.  We 
would  like  to  take  advantage  of  the  compositional  nature  of  such  protocols  to  split  the  large  verification  task 
into  separate,  more  manageable  pieces.  Existing  proof  systems  do  not  provide  a  structured  environment 
for  compositional  reasoning  about,  systems.  The  goal  of  our  work  is  to  develop  such  an  environment.  This 
environment  would  combine  the  power  of  compositional  reasoning  with  the  rigor  of  mechanically-checked 
proofs.  We  would  like  the  resulting  system  to  be  useful  in  verification  of  security  protocols  of  real-life 
size  and  complexity.  Toward  that  goal  we  have  conducted  a  case  study  in  compositional  verification  of  a 
private  communication  protocol  with  the  aid  of  the  automated  proof  tool  Isabelle.  This  paper  describes  our 
experiences  with  the  case  study. 

I/O  automata  [Lyn96,  LT89]  have  been  successfully  employed  in  hand  verification  of  large  reactive  sys¬ 
tems.  I/O  automata  express  reactive  distributed  systems  concisely  as  compositions  of  several  smaller  sub¬ 
systems.  Meta-theorems  about  compositional  properties  of  I/O  automata  help  prove  correctness  theorems 
about  the  systems  they  describe. 

Nancy  Lynch  has  applied  the  I/O  automata  formalism  to  verifying  a  private  communication  proto¬ 
col  [Lyn99].  In  this  paper  we  take  a  version  of  the  same  protocol  and  verify  its  properties  using  the  theorem 
prover  Isabelle  and  I/O  automata  meta-theory  developed  by  Olaf  Muller  [Miil98].  The  protocol  is  decom¬ 
posed  into  two  components  whose  properties  are  proven  separately.  The  top-level  proofs  then  combine 
correctness  theorems  about,  the  components  and  obtain  a  correctness  proof  about  the  composite  protocol. 
The  resulting  formal  description  could  be  further  combined  with  other  security  protocol  components,  and 
such  compositions  can  be  verified  in  Isabelle  using  the  same  compositional  reasoning  techniques. 

The  rest  of  this  paper  is  organized  as  follows.  Section  2  gives  an  introduction  to  I/O  automata  and 
the  meta-theorems  used  in  the  Isabelle  proofs.  Section  3  describes  two  recent  efforts  to  incorporate  I/O 
automata,  into  mechanical  theorem  pro  vers  PYS  and  Isabelle.  Sections  4  and  5  discuss  our  experiences  with 
verifying  a  private  communication  protocol  of  I/O  using  the  Isabelle  theorem  prover.  In  section  6  we  discuss 
our  results. 


2  An  Introduction  to  I/O  Automata 

The  Input/Output  Automaton  (I/O  Automaton)  model  [Lyn96,  LT89]  is  a  general  model  used  for  formal 
descriptions  of  distributed  reactive  systems.  An  I/O  Automaton  A  is  a  state  machine  in  which  the  state 
transitions  are  associated  with  named  actions.  The  actions  are  classified  as  either  input ,  output ,  or  internal. 
The  input  and  output  actions  are  called  external  actions.  We  let  ext  (A)  designate  the  set  of  external  actions 
of  automaton  A.  External  actions  are  used  for  communication  with  the  automaton’s  environment,  while  the 
internal  actions  are  visible  only  to  the  automaton  itself. 

I/O  Automata  state  machines  are  typically  given  in  a  precondition-effect  style.  For  each  action,  the  code 
specifies  the  preconditions  under  which  the  action  is  permitted  to  occur,  as  a  predicate  on  the  automaton 
state,  and  the  effects  of  the  action  on  the  automaton  state.  The  effects  may  be  given  as  a  series  of  imperative 
statements,  in  which  case  it  is  understood  that  all  of  the  effects  occur  in  one  atomic  step. 

The  composition  operator  ||  allows  an  automaton  representing  a  complex  system  to  be  constructed  by 
composing  automata  representing  individual  system  components.  The  composition  identifies  actions  with 
the  same  name  in  different  component  automata.  When  any  component  automaton  performs  a  step  involving 
an  action  7r,  so  do  all  component  automata  that  include  7r.  The  state  of  the  composition  is  the  product  of 
the  states  of  its  components. 
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When  we  compose  a  collection  of  automata,  output  actions  of  the  components  become  output  actions  of 
the  composition,  internal  actions  of  the  components  become  internal  actions  of  the  composition,  and  actions 
that  are  inputs  to  some  components  but  outputs  of  none  become  input  actions  of  the  composition. 

A  triple  (s,  7r,  s')  is  a  step  of  an  I/O  automaton  A  if  A  has  a  transition  from  state  s  to  state  s'  via,  action 
7 r.  An  execution  fragment  of  A  is  a  finite  or  infinite  sequence  so7r0si7ri  ...  of  alternating  states  and  actions 
of  A,  where  each  subseqence  5771757+1  is  a  step  of  A.  An  execution  of  A  is  an  execution  fragment  whose 
first  state  is  a  start  state  of  A.  The  trace  of  an  execution  a  is  the  subsequence  7  of  a  consisting  of  external 
actions  of  A.  The  set  of  all  traces  of  A  is  designated  traces(A). 

Let  7  be  a  finite  (possibly  empty)  sequence  of  external  actions  of  automaton  A,  and  let  s  and  t  be  states 
of  A.  The  triple  (5,7,/)  is  a  move  of  A  (written  5  ^>A  t)  if  there  exists  a  finite  execution  fragment  a  of  A 
starting  in  s  and  ending  in  t  such  that  trace(a)  =  7.  Thus,  a  move  s  t  is  a  series  of  state  transitions 
with  the  externally-visible  behavior  7. 

For  reasoning  about  correctness  properties  of  I/O  automata,  we  use  the  notion  of  implementation  relation , 
also  called  trace  inclusion. 

Definition  2.1.  Given  two  I/O  automata  A  and  C  with  sets  of  identical  external  actions ,  we  say  that  C 
implements  A  (denoted  C  ■<  A)  iff  traces  (C)  C  traces  (A).  D 

Implementation  relations  are  used  to  show  that  a  concrete  system  C  safely  implements  an  abstract  system 
A.  Typically,  A  is  a  specification  of  safety  properties  we  would  like  the  concrete  system  to  exhibit.  Proving 
the  relation  C  <  A  guarantees  that  C  exhibits  only  the  external  behaviors  allowed  by  the  specification  A. 

Implementation  relations  can  be  established  by  exhibiting  simulation  relations  between  the  concrete  and 
abstract  automata. 

Definition  2.2.  Let  C  and  A  be  I/O  automata,  with  identical  external  actions.  A  forward  simulation  from 
C  to  A  is  a  relation  R  over  states (C )  x  states(A)  that  satisfies  the  following  conditions: 

•  If  s  is  a  start  state  of  C ,  then  their  is  a  start  state  s'  of  A  such  that  {s,s')  E  R . 

•  If  state  s  is  reachable  in  Cf  state  s'  E  is  reachable  in  A ,  a  E  ext(C ).  and  (s,a,t)  is  a  step  of  C, 
then  there  is  a  move  s'  =LA  tf  in  A ,  where  tf  E 

Intuitively,  every  externally  visible  step  (s,a,t)  of  automaton  C  is  simulated  by  a  move  s'  t'  of 
automaton  A.  The  move  must  include  exactly  one  external  action  a,  but  may  include  any  finite  number  of 
internal  actions. 

We  write  C  <r  A  when  there  is  a  forward  simulation  from  C  to  A.  The  utility  of  forward  simulations  is 
established  by  the  following  theorem. 

Theorem  2.1.  Let  C  and  A  be  I/O  automata  with  identical  external  actions.  If  C  <f  A,  then  C  ■<  A. 

In  this  paper  we  make  use  of  two  weaker  forms  of  forward  simulations:  refinement  mappings  and  weak 
refinement  mappings.  A  refinement  mapping  is  a  restricted  form  of  forward  simulations  that  allows  each 
state  of  the  concrete  automaton  C  to  be  related  to  exactly  one  state  of  the  abstract  automaton  A.  Weak 
refinement  mappings  are  further  restricted.  They  allow  the  abstract  automaton  A  to  simulate  a  step  of  the 
concrete  automaton  C  by  at  most  one  step. 

Definition  2.3.  Let  C  and  A  be  I/O  automata  with  identical  external  actions.  A  refinement  mapping  from, 
C  to  A  is  a  function  M  from  states  (C)  to  states(A)  that  satisfies  the  following  conditions: 

•  If  s  E  start  (C)  then  M(s)  E  start  (A). 

•  If  state  s  is  reachable  in  C,  a  E  ext(C ),  and  (s,a,t)  is  a  step  of  C ,  then  state  M(s)  is  reachable  in  A 
and  there  is  a  move  M(s)  => A  M(t)  in  A. 
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Definition  2.4.  Let  C  and  A  be  I/O  automata  with  identical  external  actions .  A  weak  refinement  mapping 
from  C  to  A  is  a  function  M  from  states(C)  to  states(A)  that  satisfies  the  following  conditions: 

•  If  s  G  start  (C)  then  M(s)  G  start  (A). 

•  If  state  s  is  reachable  in  Cf  a  G  ext(C),  and  (5,  a,t)  is  a  step  of  C,  then  state  M(s)  is  reachable  in  A 
and  (M (s) ,  a,  M (t))  is  a  step  of  A. 

It  is  trivial  to  show  that  weak  refinement  mappings  are  refinement  mappings,  and  that  refinement  mappings 
are  forward  simulations. 

To  prove  trace  inclusion  C  ■<  A  by  hand,  one  usually  performs  the  following  steps: 

•  Find  a  simulation  relation  R  (or  a  refinement  mapping  M)  over  the  states  of  C  and  A. 

•  Roughly  speaking,  to  prove  that  the  relation  R  is  a  simulation,  for  each  transition  (s,  a,t)  of  C  that 

begins  with  a  reachable  state  s,  and  for  each  state  s'  G  R[s]  reachable  in  >1,  we  must  exhibit  a  transition 
(s',  a,/')  of  .4,  where  t'  G  R[t]- 

The  proof  usually  proceeds  by  induction  on  the  length  of  the  execution  leading  up  to  the  state  s.  For 
the  base  case,  we  verify  that  each  start  state  of  C  has  an  i?- related  start  state  of  A .  For  the  inductive 

step,  we  consider  each  transition  ($,  a,  /)  of  C  that  starts  in  a  reachable  state  s.  For  each  s'  G  R[s]  we 

exhibit  a  transition  (s/ajl)  of  A  and  prove  that  (t,t')  G  R. 

•  During  the  proof  of  the  inductive  step,  showing  (/,/')  G  R  sometimes  requires  us  to  place  constraints  on 
the  possible  values  of  t  and  tf .  Here  it  is  often  helpful  to  prove  invariant  properties  about  the  reachable 
states  of  C  and  A .  These  invariant  properties  provide  us  with  the  necessary  constraints  on  t  and 

The  following  theorem  defines  compositional  properties  of  I/O  automata  and  enables  us  to  reason  about 
individual  components  of  complex  systems. 

Theorem  2.2.  Let  C  =  C i||  •  •  •  1 1 Cn  and  A  =  Ai\  \  . . .  ||T„  be  parallel  compositions  of  I/O  automata,  where 
ext(Aj)  =  ext(Ci)  and  Q  <  Aj  for  every  i.  Then  ext  (A)  =  ext(C)  and  C  •<  A. 

Hence,  if  we  can  decompose  complex  systems  C  and  A  into  simpler  components,  we  can  prove  trace  inclusion 
between  C  and  A  by  proving  trace  inclusion  between  individual  components  and  then  applying  Theorem  2.2. 


3  I/O  Automata  and  Mechanical  Theorem  Proving 

When  a  trace  inclusion  proof  is  attempted  using  a  typical  generic  theorem  prover,  many  issues  crop  up. 
The  first  question  is  how  I/O  automata  should  be  represented  in  the  specification  language  of  the  theorem 
prover.  The  language  may  lack  expressive  power  or  convenient  features  because  the  language  is  tailored  for 
the  theorem  prover,  rather  than  the  user’s  needs. 

Once  the  representation  has  been  designed,  it  is  necessary  to  verify  that  the  representation  satisfies  the 
meta-theorems  about  I/O  automata,  in  particular  Theorems  2,1  and  2.2.  These  essential  theorems  may  be 
difficult  to  prove  for  the  chosen  representation  of  I/O  automata.  One  possible  solution  is  to  supply  these 
and  other  theorems  to  the  theorem  prover  in  the  form  of  axioms.  This  approach  defeats  some  of  the  value 
of  mechanical  verification,  since  we  could  not  be  sure  that  our  representation  of  I/O  automata  is  sound. 

If  we  are  verifying  a  complex  composition  of  multiple  smaller  automata,  each  individual  automaton  has 
to  be  hand- translated  to  the  input  language  of  the  theorem  prover-a,  laborious  process  that  is  prone  to  error. 
In  our  experience,  subsequent  attempts  to  prove  properties  of  the  system  reveal  many  more  errors  resulting 
from  faulty  translations  than  errors  inherent  in  the  original  I/O  automata  specification. 

The  process  of  proving  theorems  about  automata  in  a  theorem  prover  can  be  tedious.  Prover  commands 
are  typically  very  different  from  the  reasoning  steps  that  humans  usually  make.  Even  if  the  user  knows  how 
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auto  =  IOA  +  Action  +  ..1..  + 
types 

auto_state  =  ..2.. 
consts 

autojasig  ::  action  signature 
auto_trans  ::  (action,  autojstate)  transition  set 
autoJoa  ::  (action,  autojstate)  ioa 
defs 

auto_asig_def  “autojasig  ==  ({..3..},  {..4..},  {..5..})” 
auto_trans-def  “auto_trans  == 

{  tr.  let  s  =  fst(tr); 

t  =  snd(snd(tr)); 
cv  =  fst(snd(tr)) 
in 

case  q  of 

.♦6..  =>  ..7,.  | 


8 

autoJoa.def  “autoJoa  ==  (autojasig,  {..9..},  auto.trans,  {..10..},  {..11..})” 

end 


Figure  1:  Template  for  specifying  I/O  automata  in  Isabelle 


the  high-level  proof  should  go,  translating  this  knowledge  into  a  complete  proof  in  a  mechanical  prover  can 
be  a  frustrating  experience. 

Recent  work  has  addressed  these  complications  and  attempted  to  make  automated  verification  of  I/O  au¬ 
tomata  systems  more  closely  resemble  hand  verification.  Myla  Archer  et  al  recently  developed  TAME  [AHS98], 
a  high-level  interface  to  the  higher-order  logic  theorem  prover  PVS  for  specifying  and  proving  invariant 
properties  of  I/O  automata  models.  The  TAME  interface  provides  a  template  for  translating  I/O  automata 
specifications  into  the  PVS  input  language.  A  set  of  high-level  commands  lets  the  user  prove  invariant  prop¬ 
erties  with  the  same  type  of  steps  that  are  commonly  taken  in  hand  proofs.  However,  TAME  has  significant 
shortcomings  as  well.  There  is  no  natural  wa}r  to  define  an  I/O  automaton  type  and  formalize  I/O  meta- 
theory,  including  the  composition  operator  and  theorems  about  simulations  and  compositional  reasoning. 
This  is  due  to  restrictions  in  the  polymorphic  features  of  the  PVS  specification  language.  Hence,  TAME  is 
suitable  primarily  for  verifying  invariant  properties  of  relatively  small  systems. 

Ola.f  Muller  formalized  a  large  part  of  the  basic  I/O  automata  meta-theory  using  the  theorem  prover 
Isabelle  [Miil98].  Isabelle  specification  language  has  rich  polymorphic  mechanisms,  making  it  suitable  for 
consise  specifications  of  I/O  automata  and  associated  operators.  Muller’s  meta-theory  includes  a  definition 
of  the  composition  operator  and  proofs  of  Theorems  2.1  and  2.2.  We  used  Muller’s  Isabelle/IOA  system  for 
our  case  study. 


4  Trace  Inclusion  Proofs  in  Isabelle/IOA 

The  first  step  in  the  verification  process  is  converting  I/O  automata  specification  and  implementation  (written 
in  the  traditional  precondition- effect  style)  into  the  Isabelle  input  language.  This  task  is  reasonably  easy 
because  Isabelle/IOA  contains  the  composition  operator,  an  operator  for  hiding  external  actions  (which 
helps  make  automata  compatible  for  composition),  and  other  standard  operators  from  I/O  automata,  theory. 
It  is  therefore  not  necessary  to  compose  automata  by  hand,  or  otherwise  modify  them  before  doing  the 
translation. 

A  template  for  formalizing  automata  in  Isabelle’s  language  is  shown  in  Figure  1.  The  template  assumes 
that  the  actions  of  the  automaton  have  been  defined  as  a  datatype  action  in  a  separate  theory  named 
Action.  To  create  a  specific  automaton  out  of  the  template,  the  user  must  fill  in  items  1  through  11  (marked 
in  bold  numbers  in  the  figure),  as  follows. 
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The  definition  auto„trans_def  specifies  the  transition  relation  on  the  state  of  the  automaton  using  set 
comprehension  notation.  The  relation  is  a  set  of  triples  tv  —  (s,a, /)  satisfying  the  boolean  case  expression 
on  the  action  name  a.  The  user  fills  out  items  6  through  8  to  set  up  the  transition  relation  for  a  specific 
inst  antiation  of  the  template.  Items  6  and  7  pair  an  action  name  with  a  boolean  expression  constraining  the 
set  of  transitions  labeled  by  the  action  name.  All  other  actions  of  the  automaton  follow  in  item  8,  using  the 
same  syntax. 

Finally,  the  definition  auto_ioa_def  defines  the  entire  I/O  automaton  as  a  5-tuple  consisting  of  the 
action  signature,  the  set  of  initial  states  (item  9),  the  transition  relation,  and  two  types  of  fairness  conditions 
(items  10  and  11).  In  this  paper  we  will  consider  only  safety  properties,  so  the  fairness  conditions  will  always 
be  empty  sets.  Section  5.1.1  contains  an  example  translation  of  an  I/O  automaton  into  Isabelle  using  the 
template. 

Once  the  I/O  automata  have  been  encoded  in  Isabelle,  the  next  step  is  stating  and  proving  invariant 
properties  that  will  be  used  later  in  the  implementation  proof.  A  typical  hand  invariant  proof  proceeds  by 
induction.  For  the  base  case,  we  show  that  the  invariant  holds  in  all  initial  states.  For  the  inductive  step, 
we  check  that  each  action  preserves  the  invariant  property.  A  similar  strategy  works  in  our  Isabelle  proofs 
of  invariant  properties.  We  have  developed  an  Isabelle  tactic  (called  simplif y J.nv^goalJtac)  that  takes 
the  invariant  goal,  applies  induction  (thereby  breaking  the  goal  into  subgoals  for  the  base  case  and  for  each 
action)  and  automatically  proves  the  "trivial”  cases.  In  particular,  the  cases  that  do  not  modify  the  parts 
of  the  state  involved  in  the  invariant  are  proven  automatically.  After  this  tactic  is  applied,  the  user  is  left 
with  the  task  of  proving  the  remaining  cases.  In  each  case,  the  necessary  reasoning  is  localized  to  the  effects 
of  one  action,  eliminating  the  need  to  reason  about,  the  entire  automaton.  Appendix  A. 7  shows  an  Isabelle 
proof  of  one  of  the  invariants  as  an  example. 

The  final  step  in  the  implementation  proof  is  exhibiting  a  simulation  relation  or  a  refinement  mapping 
from  the  states  of  the  implementation  to  the  states  of  the  specification.  The  proof  that  a  function  is  a 
refinement  mapping  is  structurally  similar  to  the  proofs  of  invariant  properties.  Once  again,  we  apply 
induction  on  the  length  of  the  execution  to  the  goal  and  automatically  discharge  the  "trivial”  cases  among 
the  resulting  subgoals.  The  rest  of  the  subgoals  are  proven  in  the  manner  similar  to  the  hand  proof.  Each 
subgoal  corresponds  to  one  step  of  the  implementation  automaton;  the  user  must  exhibit  a  corresponding 
move  of  the  specification  automaton  and  prove  that  the  end  states  of  the  implementation  step  and  the 
specification  move  are  related  by  the  refinement  mapping. 

When  we  want  to  generate  a  trace  inclusion  proof  between  two  compositions  of  automata  C  =  (7i|| . . .  ||(7n 
and  A  =  A\  || . . .  ||An,  we  can  take  advantage  of  Theorem  2.2.  Once  we  have  obtained  separate  trace  inclusion 
proofs  for  each  pair  of  component  automata  Cj  and  A\  separately,  we  can  apply  the  compositionality  theorem 
to  get  trace  inclusion  between  C  and  A.  This  step  is  easy,  and  requires  only  a  side  proof  that  the  automata 
being  composed  are  compatible  with  each  other.  We  are  developing  Isabelle  tactics  that  discharge  most  of 
this  proof  automatically. 


5  Case  Study:  Verification  of  a  Private  Communication  Protocol 

We  have  taken  a  modified  version  of  a  private  communication  service  protocol  specified  as  I/O  automata 
in  [Lyn99]  and  used  Muller’s  Isabelle/IOA  to  verify  secrecy  properties  of  the  service.  The  main  point  of 
this  exercise  is  to  investigate  the  feasibility  of  using  the  theoretical  machinery  provided  by  I/O  automata  to 
perform  compositional  analysis  of  complex  systems  in  an  automated  proof  environment.  A  full  description  of 
the  system  together  with  the  proofs  appears  in  the  Appendices.  In  the  rest  of  the  paper  we  give  a  high-level 
description  of  the  system  and  discuss  our  experiences  with  Isabelle/IOA. 

The  private  communication  service  is  specified  as  an  I/O  automaton  PC.  The  service  lets  clients  exchange 
messages  with  each  other  using  an  insecure  transmission  channel.  The  specification  guarantees  that  messages 
are  delivered  at  most  once,  and  their  content  remains  secret  from  the  adversary. 

The  service  is  implemented  using  a  shared-key  cryptosystem  and  contains  a  number  of  automata.  Before 
going  out  on  the  insecure  communication  channel ,  each  message  passes  through  an  encoder  automaton  and 
gets  encrypted  with  a  key  that  the  encoder  shares  with  a  corresponding  decoder  automaton  on  the  receiving 
side.  The  decoder  decrypts  the  messages  and  passes  them  on  to  the  client.  The  implementation  model 
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Figure  2:  Composition  PCImpli  implements  specification  PC 


also  includes  a  passive  eavesdropper  automaton.  The  eavesdropper  can  intercept  messages  appearing  in 
the  insecure  channel  and  also  compute  new  messages  (via  encryption  and  decryption  functions)  from  the 
available  information.  Using  a  technique  similar  to  assume-guarantee  proofs,  the  environment  automaton 
records  our  assumptions  about  the  environment  in  which  the  service  can  operate  correctly.  In  particular, 
the  environment  must  not  give  away  secrets  to  the  eavesdropper. 

The  shared  keys  are  generated  by  a  key  distribution  service.  The  full  implementation  employs  a  version  of 
the  Diffie-Hellman  protocol  to  generate  and  distribute  shared  keys.  Since  the  analysis  of  key  distribution  is 
fairly  involved,  we  decompose  the  implementation  into  two  parts  that  can  be  verified  independently.  Figure  2 
shows  the  structure  of  an  I/O  automata  composition  PCImpli  =  IC\\Eve\\KD\\Enc\\Dec\\Env  implementing 
specification  PC. 

In  PCImpli ,  KD  is  a  high-level  specification,  leaving  out  the  details  of  key  distribution  and  thus  simplify¬ 
ing  the  structure  of  PCImpli .  The  Diffie-Hellman  key  distribution  protocol  can  now  be  verified  independently 
of  the  rest  of  the  private  communication  protocol.  The  protocol  consists  of  Diffie-Hellman  nodes  (one  per 
client)  and  an  insecure  channel.  Diffie-Hellman  nodes  exchange  several  messages  over  the  channel  in  order  to 
establish  a  shared  key  for  a  pair  of  clients.  Just  as  in  the  private  communication  implementation,  there  is  a 
passive  eavesdropper  and  and  an  environment.  Figure  3  shows  the  structure  of  an  I/O  automata  composition 
KDImpl  =  DHi  \  \DH2\\IC\\Eve\\Env  implementing  specification  KD. 

For  simplicity,  we  assume  (unrealistically)  that  the  key  distribution  protocol  and  the  private  communica¬ 
tion  protocol  have  separate  insecure  channels  and  eavesdroppers,  and  the  eavesdroppers  do  not  communicate 
with  each  other.  See  [Lyn99]  for  a  more  realistic  treatment  combining  the  insecure  channels  and  the  eaves¬ 
droppers. 

Breaking  up  the  implementation  in  this  manner  lets  us  take  advantage  of  the  compositionality  theorem 
about  I/O  automata  (Theorem  2.2).  We  prove  trace  inclusion  for  compositions  shown  in  Figures  2  and  3 
in  Isabelle.  Theorem  2.2  then  lets  us  substitute  the  Diffie-Hellman  implementation  KDImpl  in  place  of  the 
specification  I<D  while  preserving  trace  inclusion  between  PCImpli  and  PC.  The  resulting  implementation 
PCImpU  is  shown  in  Figure  4. 

Below  we  give  a  more  detailed  description  of  the  PC  and  I\D  service  specifications.  Appendices  A  and  B 
describe  the  compositions  PCImpli  and  KDImpl  and  give  high-level  descriptions  of  Isabelle  trace  inclusion 
proofs  for  Figures  2  and  3.  Appendix  C  shows  how  the  compositionality  theorem  is  applied  to  obtain  the 
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- - 

PC 

v _ 


Figure  4:  Composition  PCImpU  implements  specification  KD 


implementation  relation  for  Figure  4. 


5.1  The  Services 

In  this  section,  we  describe  the  two  services  that  are  implemented  by  the  protocols  and  verified  in  this  paper. 
The  use  of  input  and  output  actions  provides  convenient  ways  of  composing  these  automata  with  others,  and 
of  describing  what  is  preserved  by  implementation  relationships.  These  specifications  describe  only  safety 
properties,  although  the  same  methods  can  be  used  to  handle  liveness  properties,  formulated  as  live  I/O 
Automata  [GSSL93]. 

5.1.1  Private  Communication 

This  section  contains  a  specification  of  the  problem  of  achieving  private  communication  among  the  members 
of  a  finite  collection  P  of  clients.  The  specification  expresses  three  properties:  (1)  only  messages  that  are 
sent  are  delivered,  (2)  messages  are  delivered  at  most  once,  and  (3)  none  of  the  messages  are  revealed  by  an 
“adversary.”  We  describe  the  problem  using  a  high-level  I/O  automaton  specification  PC(U,  P,  M,A),  where 
U  is  a  universal  set.  of  data  values,  P  is  an  arbitrary  finite  set  of  client  ports,  M  C  U  is  a  set.  of  messages, 
and  .4  is  an  arbitrary  finite  set.  of  adversary  ports.  This  specification  makes  no  mention  of  distribution  or 
keys;  these  aspects  will  appear  in  implementations  of  this  specification,  but  not  in  the  specification  itself. 
The  specification  simply  describes  the  desired  properties,  as  an  abstract,  machine.  As  usual  for  automaton 
specifications,  the  properties,  listed  separately  above,  are  intermingled  in  one  description. 


PC(U,P,  M,  A): 

Signature: 

Input: 

PC-send(m)P)q ,  m  £  M,  p,q  £  P,  p  ±  q 


Output: 

PC-receive(u)p,q,  u  £  U ,  p,  q  £  P ,  p  ±  q 
reveal  (u) a,  u  £  U,  a  £  A 


States: 

for  every  pair  p,q  £  P ,  p  ^  q: 
buffer (p,  q),  a  multiset  of  M 

Transitions: 

PC-send{m)P;q 

Effect: 

add  m  to  buffer  (p,q) 

PC- receive  (u)Ptq 
Precondition: 

u  £  buffer (p,q) 

Effect: 

remove  one  copy  of  u  from  buffer (p ,  q) 


reveal  (u)  a 

Precondition: 

u  (fc  M 
Effect: 

none 


The  first  two  properties  listed  above,  which  amount  to  at-most-once  delivery  of  messages  that  were  actually 
sent,  are  ensured  by  the  transition  definitions  for  PC-send  and  PC-receive.  The  third  property,  privacy,  is 
expressed  by  the  constraint  for  reveal. 

The  following  figure  demonstrates  the  private  communication  specification  translated  into  Isabelle/IOA. 
The  translation  fills  in  specific  information  about  the  specification  into  the  template  shown  in  section  4. 


PC  =  IOA  +  Action  +  InfMultiset  + 
types 

PC_state  =  “P  X  P  ^  U  tmultiset” 
consts 

PC_asig  ::  action  signature 

PC.trans  ::  (action,  PC_state)  transition  set 

PCJoa  ::  (action,  PC_state)  ioa 
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clefs 


PC_asigjdef  “PCjasig  == 

((lTN  ni  p  q.  {PCjsend  in  p  q}). 

(UN  u  msg  p  cj.  {PC'.receive  n  msg  p  q})  U  (UN  u  a.  {reveal  u  a}), 
{})” 

PC-transjdef  “PO.trans  == 


{  tr.  let  s  =  fst(tr); 

t  =  snd  ( snd  ( tr) ); 
o  =  fst(snd(tr)) 
in 

case  o  of 

reveal  u  a  =>  u  £  M_set  | 

PC_send  m  p  q  => 

(in  £  M_set)  k 
(t  =  (A  (p\  q  ). 

if  (p  =  p?)  k  (q  =  q’)  then 

s  (p\  q')  +  {m} 

else 

s  (pN  ci’)))  | 

PC- .receive  n  msg  p  q  =>• 

(u  e  s  (p.  ci ) )  & 

(t  =  (A  (p\  c,’). 

if  (p  =  p’)  k  (cj  =  cf)  then 

s  (p*,  q  )  -  {u} 

else 


}" 


S  (p’>  <l’))) 


end 


PC!_ioa_def  “PCJoa  ==  (PCUasig,  {A  (p,  ci).  0),  PC.trans.  {},  {})" 


The  state  of  PC  is  represented  as  a  function  from  a  pair  of  clients  of  type  P  to  a  multiset  of  messages  of 
type  V .  The  definition  of  the  transition  relation  gives  a  boolean  expression  for  every  triple  (s,a  ,  t),  where  s 
and  t  are  states  and  a  is  an  action  of  PC.  The  boolean  expression  includes  the  precondition  of  a  and  relates 
t  to  s  via  the  effects  of  a.  Thus,  the  expression  is  true  if  and  only  if  (s,  a,t)  is  a  step  of  PC. 


5.1.2  Key  Distribution 

This  is  a  drastically  simplified  key  distribution  service,  which  distributes  a  single  key  to  several  participants. 
We  do  not  model  requests  for  the  keys,  but  assume  that  the  service  generates  the  key  spontaneously.  The 
simplified  key  distribution  problem  is  specified  by  the  automaton  I\D(U ,  P,  A’,  .4),  where  U  is  a  universal  set 
of  data  values,  P  is  an  arbitrary  finite  set  of  client  ports,  K  C  U  is  a  set  of  keys,  and  A  is  a  finite  set  of 
adversary  ports. 

KD(U,  P,K,A): 

Signature: 

Input:  Internal: 

none  choost-key 

Output: 

grant (u)p,  u  £  U,  p  €  P 
reveal  (  u) a ,  u  £  U ,  a  £  A 


States: 

chosen-kty ,  an  element  of  K  U  {X},  initially  X 
notified  C.  P,  initially  0 

Transitions: 
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choost-key 

Precondition: 

chosen-key  —  X. 

Effect: 

chosen-key  :=  choose  k  where  k  E  K 


reveal  (u)  a 

Precondition: 

u  £  I\ 
Effect: 
none 


grant  [u)p 

Precondition: 

chosen-key  ^  -L 
u  =  chosen-key 
p  (fc  notified 
Effect: 

notified  :=  notified  U  { p } 


6  Discussion 

The  benefits  of  decomposing  large  systems  into  smaller  parts  for  verification  are  twofold.  From  the  software 
engineering  perspective,  formalizing  and  reasoning  about  large  monolithic  systems  quickly  becomes  unman¬ 
ageable.  The  number  of  potential  interactions  between  state  components  typically  increases  exponentially 
with  the  size  of  the  state  and  the  size  of  the  transition  relation.  When  the  system  has  more  than  a  few  state 
components,  just  formulating  the  necessary  invariants  can  prove  to  be  a  daunting  task.  Compositional  rea¬ 
soning  lets  us  take  a  modular  approach  to  verification.  We  can  focus  on  proving  properties  of  self-contained 
systems  of  reasonable  size  and  build  up  a  component  library  for  constructing  larger  systems.  Composition- 
ality  results  let  us  combine  proven  properties  of  components  and  obtain  new  results  about  the  larger  system 
without  going  through  the  verification  process  from  scratch.  One  can  imagine  that  somewhat  more  realistic 
versions  of  the  PC  and  KD  services  and  their  implementations  could  be  a  part  of  a  library  of  formalized 
security  and  cryptography  components. 

Decomposition  also  helps  avoid  the  state  explosion  problems  common  to  all  automated  verification  tools. 
Isabelle’s  simplifier  was  valuable  in  reducing  the  human  effort  in  our  verification  exercise,  but  in  our  ex¬ 
perience  its  running  time  greatly  depends  on  the  size  of  automata  being  verified.  The  table  below  shows 
the  running  time  on  a  set  of  theorems  proven  automatically  by  an  identical  invocation  of  the  simplifier. 
Each  theorem  describes  how  a  transition  of  an  n- automat  a  composition  is  projected  onto  the  individual 
components.  The  table  gives  the  timings  for  n  G  {3, 4,  5,  6}. 


n 

3 

4 

5 

6 

time 

5.5  sec 

27.9  sec 

3.8  min 

40.1  min 

We  did  not  prove  the  theorems  for  higher  values  of  n  because  for  n  >  7  the  simplifier  requires  more  than 
the  256MB  of  RAM  available  on  the  test  machine.  But  the  data  in  the  table  suggest  that  even  without 
the  space  restriction,  the  automatic  proof  tools  in  Isabelle  would  not  be  able  to  handle  larger  systems  in 
a  reasonable  amount  of  time,  and  without  them  the  verification  effort  is  prohibitively  expensive.  In  the 
small  example  verified  in  this  paper,  we  split  the  task  of  verifying  trace  inclusion  for  a  nine-component 
system  PCImplo  into  two  separate  tasks,  one  of  which  deals  with  a.  six-component  system  PCImpli  and 
the  other  with  a  five-component  system  KDImpl.  Notably,  we  could  not  prove  the  projection  theorems  for 
the  nine-component  case,  but  could  do  so  for  the  smaller  component  cases.  This  modest  division  resulted 
in  substantial  savings  primarily  because  complexity,  running  time,  and  space  requirements  appear  to  be 
exponentially  related  to  problem  size.  In  the  context  of  real-world  systems  that  can  have  dozens  of  such 
components,  abstraction  and  decomposition  become  essential. 


6.1  Observations  on  Benefits  of  Formal  Verification 

Refinement  proofs  turned  out  to  be  a  more  effective  way  of  fleshing  out  specification  problems  than  invariant 
proofs.  Invariant  proofs  may  touch  only  specific  parts  of  the  protocol  state  and  leave  untouched  more  abstract 
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questions  about  what  the  protocol  is  doing.  The  refinement  proof  makes  explicit  all  the  assumptions  about 
why  the  implementation  does  what  the  specification  intended. 

In  particular,  during  the  refinement  proof  for  the  implementation  PCImplj  we  were  forced  to  go  back 
and  prove  several  auxiliary  invariants  whose  utility  were  not  obvious  a  priori.  This  in  turn  led  us  to  typos 
and  errors  in  our  formalization  of  t  he  cryptosystems  and  component  automata.  Although  the  bugs  caught 
during  the  process  of  proving  invariant  lemmas  and  trace  inclusion  were  mostly  errors  in  our  formalization, 
we  caught  one  error  in  the  original  description  of  PCImplj  protocol  (some  uninitialized  variables  led  to  failed 
proofs  of  the  base  case)  and  a  typo  in  an  invariant  statement  in  [LynQQ]  (see  remark  about  invariant  B.l  in 
Appendix  B.3). 

6.2  Efficiency  Issues 

The  human  effort  spent  on  the  project  included  (1)  twelve  weeks  for  formalizing  and  verifying  PCImplj  <  PC , 
(2)  three  weeks  for  verifying  KDImpl  <  I\D ,  and  (3)  three  days  for  verifying  PCImplo  <  PC.  A  substantial 
fraction  of  the  time  in  stage  1  was  spent  learning  Isabelle/IOA  and  setting  up  the  procedure  for  formalizing 
I/O  automata,  stating  and  proving  invariants,  and  proving  trace  inclusion.  This  accounts  for  most  of  the 
difference  in  effort  between  stages  1  and  2.  Stage  3  was  much  shorter  due  to  our  use  of  the  compositionality 
theorem. 

We  believe  that  additional  automation  can  reduce  the  human  effort  substantially  in  all  phases  of  the 
verification  process.  At  the  level  of  the  prover,  additional  tactics  can  automate  tasks  that  commonly  show 
up  in  reasoning  about  I/O  automata.  These  tactics  fall  into  two  categories.  One  set  of  tactics  would 
simulate  the  high-level  proof  steps  used  in  human-style  I/O  automata  proofs.  These  would  be  similar  to  the 
proof  strategies  offered  by  Archer’s  TAME  environment  for  PVS.  Another  set  of  tactics  would  help  the  user 
deal  with  proof  obligations  specific  to  Isabelle  and  the  Isabelle  formalization  of  I/O  automata  meta-theorv. 
For  example,  applying  the  compositionality  theorem  requires  proofs  for  side  conditions  that  the  Isabelle 
type  checker  does  not  guarantee.  It  must  be  shown  that  the  I/O  automata  definitions  are  well  formed  - 
the  sets  of  input,  output,  and  internal  actions  are  disjoint,  and  the  transition  relation  is  defined  only  for 
the  actions  in  the  automaton  signature  definition.  Furthermore,  the  user  must  show  that  the  automata 
being  composed  are  compatible  with  each  other.  These  proofs  have  common  structure  and  can  therefore  be 
effectively  encapsulated  in  a  higher-level  Isabelle  tactic.  The  tactic  would  be  used  with  every  application  of 
the  compositionality  theorem. 

There  are  also  ways  to  improve  efficiency  at  the  user  interface  level.  A  compiler  can  take  care  of  translating 
I/O  automata  (expressed  in  a  suitable  way)  into  an  Isabelle  formalization.  It  is  also  possible  to  generate  a 
general  framework  for  invariant  definitions  and  trace  inclusion  proofs  automatically,  letting  the  user  fill  in 
definitions  and  proof  script  details  specific  to  the  problem. 

One  of  the  biggest  obstacles  to  formal  reasoning  with  theorem  provers  remains  their  cumbersome  nature 
and  the  level  of  attention  to  low-level  details  required  of  the  user.  Isabelle  is  not  an  exception.  Interacting 
with  the  bare-bones  prover  throughout  the  verification  cycle  can  be  a  frustrating  experience,  which  is  why 
we  emphasize  the  need  to  automate  as  much  of  the  process  as  possible.  With  the  enchancements  discussed 
above,  the  task  of  formalizing  the  specification  and  setting  up  proof  goals  and  induction  can  be  substan¬ 
tially  automated.  Most  user  interaction  with  the  prover  would  take  place  when  reasoning  about  individual 
automata  actions.  The  actions  typically  have  a  small  and  localized  effect  on  the  automaton  state,  which 
makes  the  proofs  more  manageable. 

6.3  Technical  Issues 

In  Muller’s  formalization  of  I/O  automata  meta-theory  the  binary  automata  composition  operator  has  the 
following  type,  given  in  Isabelle’s  ML-like  notation: 

||  ::  (a,  cr)  ioa  — >•  ( a ,  r)  ioa  -»  (a  ,  a  x  r)  ioa 

where  cv  is  the  action  type,  a  and  r  are  state  types  of  the  automata  being  composed,  and  a  x  r  is  the 
state  type  of  the  composition.  The  composition  operator  requires  that  both  automata  be  defined  over  the 
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same  action  space  cv.  If  we  apply  the  operator  multiple  times  to  compose  several  automata,  every  action  of 
every  component  must  be  a  member  of  the  same  action  space.  Mechanized  induction  on  the  action  datatype 
generates  a  subcase  for  each  action  in  the  action  space,  including  those  that  do  not  belong  to  the  component 
being  verified.  This  means  that  inductive  proofs  do  not  scale  well  for  large  compositions  of  automata.  This 
is  a  serious  problem,  as  it  undermines  the  primary  benefit  of  compositional  reasoning:  scalability.  It  takes 
over  an  hour  for  Isabelle  (ver.  99)  to  execute  in  interactive  mode  the  invariant  and  refinement  proof  scripts 
developed  in  this  project.  The  simplifier  spends  the  majority  of  that  time  reducing  inductive  subcases  for 
actions,  considering  many  more  cases  than  necessary. 

Fixing  the  problem  without  completely  revising  the  meta-theory  requires  a.  richer  type  system  than 
supported  by  Isabelle/HOL.  For  example,  in  a  polymorphic  language  with  subtyping  and  union  types  [Pie91], 
the  composition  operator  could  be  given  the  following  type: 

||  ::  (a,  a)  ioa  — )►  (/?,  r)  ioa  — y  (a  V  8,  a  x  r)  ioa 

The  action  type  of  the  composition  a  V  f3  is  the  union  type  derived  from  the  action  types  a  and  /3  of 
the  components.  Assuming  that  the  usual  binary  operators  on  sets  (union,  intersection,  difference)  have  the 
type  a  set  -+  8  set  (o  V/?)  set ,  the  existing  definition  of  the  composition  operator  would  still  make  sense 
in  this  setting. 


7  Conclusions 

Existing  compositional  proof  methods,  including  implementation  relations  between  I/O  Automata,  are  ade¬ 
quate  for  handling  large  classes  of  verification  problems.  Numerous  case  studies  have  used  these  techniques 
by  hand  to  prove  global  properties  of  noil-trivial  systems.  Until  recently,  automated  verification  tools  have 
not  included  compositional  techniques  in  their  repertoire.  Yet,  the  strengths  of  compositional  reasoning  and 
automated  reasoning  have  the  potential  to  complement  each  other. 

Automation  demands  that  compositional  proofs  be  made  strictly  rigorous.  It  does  not  tolerate  typos 
or  imprecise  wording,  which  can  lead  to  subtle  errors  in  hand  proofs.  Forced  to  develop  proofs  according 
to  these  exacting  standards,  the  user  gains  deeper  understanding  of  the  subtleties  of  the  system  and  more 
confidence  in  the  final  product.  Although  time  consuming  to  use,  automated  proof  tools  make  proof  re¬ 
checking  much  easier,  which  can  result  in  substantial  time  savings  in  the  iterative  development /verification 
cycle.  Conversely,  compositional  techniques  offer  the  best  hope  of  dealing  with  state  explosion  and  complexity 
problems  associated  with  automated  verification  of  non-trivial  systems. 

Our  experience  with  the  Isabelle/IOA  verification  environment  leads  us  to  conclude  that  there  is  a 
lot  of  work  yet  to  be  done  before  the  potential  benefits  of  automated  compositional  reasoning  are  fully 
realized.  Using  Isabelle/IOA  is  a  labor-intensive  undertaking,  and  the  environment  does  not  appear  to  be 
sufficiently  scalable.  These  issues  can  be  resolved  with  additional  effort,  and  we  believe  that  the  benefits  of 
the  compositional  approach  make  the  effort  worthwhile. 


Acknowledgments 


The  authors  wish  to  thank  Nancy  Lynch  for  her  support  and  encouragement  for  our  project  and  her  feedback 
to  an  earlier  draft  of  this  paper. 


References 

[AHS98]  M.  Archer,  C.  Heitmeyer,  and  S.  Sims.  TAME:  A  PVS  interface  to  simplify  proofs  for  automata 
models.  UITP  ’98,  July  1998. 

[GSSL93]  R.  Gawlick,  R.  Segala,  J.F.  Sogaard- Andersen,  and  N.  Lynch.  Liveness  in  timed  and  untimed  sys¬ 
tems.  Technical  Report  MIT/LCS/TR-587,  MIT,  Laboratory  for  Computer  Science,  Cambridge, 
MA.,  December  1993. 


12 


[LT89]  N.  Lynch  and  M.  Tuttle.  An  Introduction  to  Input/Output  Automata.  CW I- Quarterly <  2(3) :219— 
246,  September  1989. 

[Lyn96]  N.  Lynch.  Distributed  Algorithms.  Morgan  Kaufmann  Publishers,  San  Mateo,  CA,  March  1996. 

[Lyn99]  N.  Lynch.  I/O  automaton  models  and  proofs  for  shared-kev  communication  systems.  12t,h  IEEE 
Computer  Security  Foundations  Workshop  (CSFW12),  pages  14-29,  June  1999. 

[Miil98]  O.  Muller.  A  Verification  Environment  for  I/O  Automata  Based  on  Formalized  Meta-Theory. 
PhD  thesis,  Technische  Universitaat  Miinchen,  1998. 

[Pie91]  B.C.  Pierce.  Programming  with  intersection  types,  union  types,  and  polymorphism.  Technical 
Report  CMU-CS-91-106,  Carnegie  Mellon  University,  February  1991. 


13 


A  Private  Communication  Implementation 


Ill  this  appendix,  we  describe  the  protocol  that  implements  the  private  communication  specification  from 
Section  5.1.1.  The  protocol  uses  a  shared-key  cryptosystem  C  to  encrypt  messages  before  sending  them  over 
an  insecure  communication  channel.  The  protocol  keeps  the  messages  secure  against  passive  eavesdroppers. 

We  give  automaton  models  for  some  system  components  that  appear  in  many  security-related  settings: 
environments  for  security  services,  insecure  channels,  and  eavesdroppers.  They  are  presented  in  a  parame¬ 
terized  fashion  so  that  they  can  be  used  in  different  contexts.  We  then  put  these  components  together  in 
the  private  communication  protocol. 

A.l  Cryptosystems 

A  cryptosystem  signature  S  consists  of: 

•  TNs ,  a.  set  of  type  names . 

•  FArs,  a  set  of  function  names. 

•  domains ,  a  mapping  from  FNs  to  (TNs)*. 

•  range s ,  a  mapping  from  FNs  to  TN s- 

•  EN s  C  FNs,  a  set  of  easy  function  names. 

A  constant  name  is  a  function  name  /  such  that  domains(f)  —  A.  Let  CNs  C  FNs  denote  the  set  of 
constant  names  of  C.  We  omit  the  subscript  S  where  no  confusion  seems  likely.  A  cryptosystem  C  consists 
of: 

•  A  cryptosystem  signature  sigc.  We  write  TNc  as  shorthand  for  TN sigc ,  etc. 

•  setc,  a  mapping  from  TNc  to  disjoint  sets. 

•  func ,  a  mapping  from  FNc  to  functions;  We  require  that  if  domainc  (/)  =  (*i , . . . ,  4)  and  rangec  (/)  =  t 
then  func(f)  :  setc(ti)  x  *  *  •  x  setc(tk)  setc{t). 

We  write  setc  for  TNc  setc  (*).  We  omit  the  subscript  C  where  no  confusion  seems  likely.  IfA^U{y}  C  setc , 
we  say  that  y  is  easily  reachable  from  X  in  C  provided  that  y  is  obtainable  starting  from  elements  of  X,  by 
applying  only  functions  denoted  by  function  names  in  EN c  • 

A.  1.1  Term  Cryptosystems 

If  S  is  a  cryptosystem  signature,  then  the  terms  of  S ,  and  their  types ,  are  defined  recursively,  as  follows: 

1.  If  c  G  CNs  and  range  s(c)  —  t ,  then  c  is  a  term  and  types (c)  =  t. 

2.  If  /  G  FNs ,  domains(f)  -  t\M,  • .  -  where  k  >  1,  ranges{f)  =  t,  and  ei, . .  .,ek  are  terms  of  types 
t tk,  respectively,  then  the  expression  e  =  f(e i,...,e*)  is  a  term,  and  types(e)  =t. 

Let  Termss{t )  denote  the  set  of  terms  of  S  of  type  t.  Let  Termss  denote  the  set  of  all  terms  of  S. 

Some  of  the  cryptosystems  we  consider  are  best  understood  as  term  algebras  derived  from  cryptosystem 
signatures.  In  these  cases,  the  values  of  the  various  types  are,  formally,  equivalence  classes  of  terms:  An 
equivalence  relation  R  on  Termss  is  said  to  be  a  congruence  provided  that  the  following  hold. 

1.  If  eRe'  then  types(e)  =  types(el). 

2.  Suppose  that  /  G  FNS,  domains(f )  =  where  k  >  1,  ranges(f)  =  t ,  are 

terms  of  types  t\ , . . . ,  tk ,  respectively,  e[ , . . . ,  e'k  are  terms  of  types  1 1 , . . . ,  tk ,  respectively,  and  for  all 
t,  1  <  i  <  k,  Re'i .  Then  /(ex, . . . ,  ek)Rf(e i, . .  .  ,€*). 
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Let  S  be  a  cryptosystem  signature  and  R  a  congruence  on  Termss.  Then  the  term  cryptosystem  C  for  S 
and  R  is  the  unique  cryptosystem  satisfying: 

•  sigc  =  5. 

•  If  /  G  TNc<  then  setc(t)  is  the  set  of  all  ^-equivalence  classes  of  terms  of  type  i  in  Termsc • 

•  If  /  G  FNc ,  domaincif)  =  (t  1, _ A)  and  rangec(f)  =  1  then  func(f)  is  the  function  from  setc(/i)  x 

•  *  ■  x  setc(t-k)  to  setc(t)  defined  as  follows.  Suppose  that  e,  G  setc(ii)  for  all  ?*,  1  <  ?’  <  A:.  Then 
fimc(f)([e i]t?i  ■  •  •  >  [e*]/?)  is  defined  to  be  [/(ei . ek)]n.  (Since  R  is  a  congruence,  this  is  well-defined.) 

We  use  the  notation  Re  for  the  congruence  relation  R  of  C.  If  c  G  Termsc ,  then  we  write  [e]c  for  the 
equivalence  class  of  e  with  respect  to  Re .  Also,  if  E  C  Termsc  then  we  write  [£]c  for  the  set  of  equivalence 
classes  [e]c  for  e  G  E. 

In  the  rest  of  this  sect  ion  we  describe  two  specific  crypt  osystems.  The  first,  kind  of  cryptosystem,  a  shared- 
key  cryptosystem,  is  used  in  shared  key  communication.  The  second  kind,  a  base-exponent,  cryptosystem,  is 
used  in  the  Diffie-Hellman  key  distribution  protocol. 

A.  1.2  Sliared-key  cryptosystems 

A  shared-key  cryptosystem  C  is  a  term  cryptosystem.  The  signature  5  =  sigc  is  defined  as  follows.  TNs 
consists  of  two  type  names:  "M"  for  messages  and  "IT "  for  keys.  FRTs  consists  of: 

•  enc,  with  domain(enc)  —  ("M" RTF')  and  range (enr)  =  “AT\ 

•  dec ,  with  domain  (dec)  ~  {"AF' ,  ‘Tv’1')  and  range  (dec)  =  "Af\ 

•  MConsts ,  a  set  of  message  constant  names,  with  range (m)  =  "A F'  for  all  m  G  MConsts • 

•  I\  Const s ,  a  set  of  key  constant  names,  with  range  (k)  =  “A’"  for  all  A1  G  KConsts . 

jEWs  =  {euc,c/ec}.  We  write  the  congruence  relation  on  terms  of  a  shared-key  cryptosystem  as  — 5 .  The 
relation  is  defined  by  means  of  all  equations  of  the  form: 

•  dcc(enc(m,  A),  A)  =  m,  where  m,  k  G  Termss ,  type(???)  =  MJlf,  tt/pe(A)  =  w/v". 

Specifically,  we  want,  the  smallest  congruence  relation  on  Termss  that  equates  all  terms  that  are  related  by 
the  given  equations.  In  Isabelle  we  define  this  relation  inductively  as  follows: 

1.  m  =lS  m  for  all  terms  m 

2.  if  mi  =f  inn  and  Aq  =s  Ao,  then  e??.c(mi ,  Aq)  =s  enc(?no,  Ao) 

3.  if  ?77 1  ==*  777 o  and  Aq  =uS  Ao ,  then  dec(m\ ,  Aq)  ==5  dec  (mo,  Ao) 

4.  if  c ?7 c (???.,  A)  =s  e,  then  rfcc(f ,  A)  =*  m 

5.  If  777 1  =s  77?o  >  then  777 o  =5  777 1 

6.  If  777 1  =  *  7772  and  7772  =5  7773,  then  777 1  7??3 

Lemma  A.l.  The  definitions  of and  =s  a?r  equivalent . 

Proof.  Suppose  that  terms  and  A  are  related  by  =5.  We  prove  that  /i  =*  to  by  induction  on  the  derivation 
of  ti  =5  to- 

Consider  the  last  rule  in  the  derivation.  There  are  six  possibilities: 
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1.  fx  —  t2  =  m.  By  reflexivity  of  =s,  =s  t 2. 

2.  =  enc(?ni,  A?x)  and  U  —  enc(m 2,k2).  By  the  inductive  hypothesis,  we  have  m x  =,  m2  and  =a  &2. 
The  result  follows  because  =s  is  a  congruence. 

3.  Similar  to  case  2. 

4.  fx  —  dec(e,k)  and  t2  =  ?n.  By  the  inductive  hypothesis,  we  have  enc[m,k)  =s  e*  Using  the  fact  the 
=a  is  a  congruence,  we  obtain  dec(enc(??i,  &),  A)  =s  c/ec(e,ft).  From  the  equations  defining  =qs  and 
transitivity  it  follows  that  m  — s  d.ec(e,  k). 

5.  Result  follows  from  symmetry  of  =5 . 

6.  Result  follows  from  transitivity  of 

Now  suppose  that  terms  t\  and  U  are  related  by  =s.  If  t\  and  U  are  related  by  the  equations  defining 
,  then  assume  that  t\  —  dec(enc(m,k),  k)  and  to  —  m  for  some  m  and  k.  We  get  t\  =s  to  by  applying 
rule  4  from  the  inductive  definition  of  =,  with  e  —  enc(m,  k). 

We  must  also  show  that  =5  is  a  congruence.  =s  is  reflexive  by  rule  1,  symmetric  by  rule  5,  transitive  by 
rule  6,  and  a  congruence  by  rules  2  and  3. 

□ 

Lemma  A. 2.  Suppose  that  is  a  term  of  type  “M  ”,  i  E  {1,2},  and  enc{  and  dec{  are  the  number  of  enc 
function  names  and  dec  functions  names  in  ei,  respectively ,  and  ex  =s  e2.  Then  enc\  —  dec  1  =  enco  —  dec2. 

Proof.  By  induction  on  the  structure  of  the  derivation  of  ex  =s  e2.  D 

A. 1.3  Base-exponent  cryptosystems 

A  base-exponent  cryptosystem  C  is  a  term  cryptosystem  in  which,  letting  S  —  sigc : 

TNs  consists  of  two  type  names,  “ B ”  for  bases  and  “A””  for  exponents. 

FN$  consists  of: 

•  exp,  with  domain(exp)  -  (“B” ,  “A”)  and  range(exp)  =  “F. 

♦  B Const s ,  a  set  of  base  constant  names,  with  rangefb)  =  for  all  b  E  BConsts • 

♦  X  Const  Is  and  ATAmsf^s,  two  disjoint  sets  of  exponent  constant  names,  with  dommn(x)  =  A  and 
ran<7e(a?)  =  “A”  for  all  #  E  XConstls  U  XConst2s • 

=  {exp}  U  BConsts ■  We  write  the  congruence  relation  on  terms  of  a  base-exponent,  cryptosystem  as 
=b.  The  relation  =5  is  defined  by  means  of  all  equations  of  the  form: 

•  ex p(exp(b,x),y)  —  exp(exp(b,  y),  x),  where  b,x,ye  Termss ,  type(b)  =  UB” ,  type(z)  =  type(y)  =  “A1’. 

In  the  Isabelle  formalization  of  base-exponent,  cryptosystems,  we  define  the  relation  =b  inductively  as 
follows: 

1 .  m  =6  ?77  for  all  terms  m 

2.  if  mi  =6  m2  and  aq  ==5  aq,  then  e:cp(mi,  aq)  =*,  exp(m2,  x2) 

3.  ea?p(earp(m,  arx),  aq)  =6  exp(exp(m,  aq),  aq) 

4.  If  mi  =6  m2 ,  then  m2  =6  mi 
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5.  If  mi  mo  and  ???2  =6  m3,  then  m i  =6 
Lemma  A. 3.  77?e  definitions  of  —b  and  =b  «re  equivalent . 

Proof  Suppose  that  terms  /]  and  /2  are  related  by  =*>.  We  prove  that  f  i  =b  to  by  induction  on  the  derivation 
of  /i  ==(,  f2.  Consider  the  last  rule  in  the  derivation.  There  are  five  possibilities: 

1.  t\  =  to  ~  m.  By  reflexivity  of  fi  =&  /2. 

2.  fi  —  e.rp(???i ,  .ri)  and  to  =  e.r/>(???2  »  *2)-  By  the  inductive  hypothesis,  we  have  mi  —b  m2  and  x\  =b  x2- 
The  result  follows  because  —i  is  a  congruence. 

3.  /i  =  exp(exp(m,  .r2)  and  to  =  exp(exp(m,  .To),  a*i ).  From  the  equations  defining  —b  it  follows 
immediately  that  t\  —b  to, 

4.  Result  follows  from  symmetry  of  —b. 

5.  Result  follows  from  transitivity  of  =&. 

Now  suppose  that  terms  t\  and  to  are  related  by  =6.  If  t\  and  to  are  related  by  the  equations  defining 
=b,  then  assume  that  f i  —  exp(€rp(b,  x),y)  and  to  =  exp(exp(b,y),  x)  for  some  b ,  x,  and  y.  We  get  t\  =*>  to 
by  applying  rule  3  from  the  inductive  definition  of  =b  with  m  =  6,  .C]  =  ,r,  and  a*2  =  y. 

We  must  also  show  that  =&  is  a  congruence.  is  reflexive  by  rule  1,  symmetric  by  rule  4,  transitive  by 
rule  5,  and  a  congruence  by  rule  2. 

□ 

Define  B2s  to  be  the  set  of  all  terms  of  the  form  exp(exp(b,  x),y),  where  b  E  B  Coasts,  x  E  X  Const  Is 
and  y  E  X Const 2s .  An  augmented  base-exponent  cryptosystem  is  a  base-exponent  cryptosystem  together 
with  a  distinguished  element  bOs  of  B Coasts . 

Lemma  A. 4.  Suppose  that  ej  is  a  term  of  type  “B ",  i  E  {1,2}.  and  expi  is  the  number  of  exp  function 
names  in  ej ,  and  e.\  =s  eo.  Then  exp1  =  exp2. 

Proof  By  induction  on  the  structure  of  the  derivation  of  e±  =b  eo.  □ 

A. 2  Environment  Automata 

Here  we  assume  that  U  is  a  universal  set  of  data  values,  A  is  an  arbitrary  finite  set  of  adversary  ports, 
that  is,  locations  where  information  can  be  communicated  to  the  adversary,  and  N  C  U .  The  environment 
automaton  Env(U,  A,  Ar)  models  any  entities  other  than  the  channels  from  which  an  eavesdropper  may  learn 
information.  It  says  that  the  environment  is  capable  of  communicating  elements  of  U  at  any  adversary  port 
a  E  A,  but  in  fact,  does  not  communicate  any  elements  of  Ar. 

Env(U,A,N)  : 

Signature: 

Input:  Output: 

None  learn  (u)a,  u  £  U,  a  £  A 

States: 

No  variables 

Transitions: 

learn  (u)  a 

Precondition: 

u  i  N 
Effect: 
none 
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A. 3  Insecure  Channel  Automata 


Here  we  assume  that  U  is  a  universal  set  of  data  values,  P  is  an  arbitrary  finite  set  of  client  ports,  and  .4 
is  an  arbitrary  finite  set  of  adversary  ports.  The  insecure  channel  admits  send  and  receive  actions  for  all 
elements  of  U  and  also  has  eavesdrop  output  actions,  by  which  information  in  transit  passes  to  an  outsider. 
The  insecure  channel  allows  any  message  in  transit  to  be  communicated  to  an  outsider  via  the  eavesdrop 
actions. 

IC(U,  P,A): 

Signature: 

Input:  Output: 

IC-$end(u)Ptq,  u  £  U ,  p,q  G  P,  p  i=-  q  IC-receive  (u)p>q,  u  £  V,  p,  q  £  P,  P  ^  q 

eavesdrop {u)p,qtai  u  €  U ,  p,q  £  P,  p  ±  q ,  a  6  A 


States: 

for  every  p,q  £  P,  p  ^  q : 

buffer  (p,  q),  a  multiset  of  U,  initially  empty 

Transitions: 

IC-$end(u}P;q 
Effect: 

add  u  to  buffer  (p,q) 

IC-receive  (u)p,q 
Precondition: 

u  £  buffer (p,  q) 

Effect: 

remove  one  copy  of  u  from  buffer (p,  q) 

A. 4  Eavesdropper  Automata 

Here  we  assume  that  C  is  a  cryptosystem,  P  is  an  arbitrary  finite  set  of  client  ports,  and  A  is  an  arbitrary 
finite  set  of  adversary  ports.  We  define  a  model  for  an  eavesdropper,  as  a  nondeterministic  automaton 
Eve(C,P,A).  Eve  simply  remembers  everything  it  learns  and  hears,  and  can  reveal  anything  it  has,  at  any 
time.  It  does  this  by  maintaining  a  variable  has ,  initially  0.  The  value  of  has  may  change  only  in  restricted 
ways:  Namely,  when  eavesdrop {u)P)Cha  or  learn(u)a  occurs,  u  gets  added  to  has.  When  an  internal  compute 
action  occurs,  the  value  resulting  from  applying  an  easy  function  (one  in  ENc)  to  values  in  has  may  be 
added  to  has.  We  restrict  the  reveal (u)  output  so  that  u  £  has,  that  is,  Eve  can  only  report  a  value  that  it 
has.  Similar  treatments  of  known  information  appear  elsewhere  in  the  literature. 

Eve(C,  P,  -4): 

Signature: 

Input:  Internal: 

eaves  drop  (u)p,qfa,  u  G  setc,  p,  q  £  P,  p  ^  q,  a  £  A  compute  (u, /)a,  /  G  ENc,  €  A 

learn  (it) 0,  u  £  setc,  a  G  A 
Output: 

reveal (u)a,  u  £  setc,  a  €  A 


States: 

has  C  setc,  initially  0 


eavesdrop  (u)ptqta 
Precondition: 

u  £  buffer (p.q) 
Effect: 
none 


Transitions: 


eavesdrop  (  u)p^q.o 
Effect : 

has  :=  has  U  {u  ) 

learn  (u)a 
Effect: 

has  :=  has  U  {«} 


re  veal  ( 

Precondition: 

u  G  has 
Effect: 
none 

compute  (u,  f)a 
Precondition: 

{{/■i . . . . ,  uk  }  C  s.has 
v  =  f(ui,...,uk) 
Effect: 

has  :=  has  U  {t/} 


The  rest  of  this  appendix  describes  a  straightforward  shared-key  communication  protocol.  The  proto¬ 
col  simply  uses  a  shared  key,  obtained  from  a  key  distribution  service,  to  encode  and  decode  messages. 
Throughout  the  section,  we  assume  that  C  is  a  shared-key  cryptosystem,  P  is  a  set  (of  clients)  with  at  least 
2  elements,  and  A  is  a  nonempty  finite  set  (of  adversaries). 


A. 5  The  Encoder  and  Decoder 

We  define  parameterized  encoder  and  decoder  automata,  parameterized  by  the  shared-key  cryptosystem  C, 
the  set  P  of  clients,  and  elements  q  £  P,  p  ^  q.  Note  that,  in  the  code  for  IC-send(u),  we  are  using  the 
abbreviation  enc  for  fun c (enc)  -  that  is,  we  are  suppressing  mention  of  the  particular  cryptosystem  C. 

Enc(C ,  P)p,q v  where  p,  q  £  P,  p  /  q  : 

Signature: 

Input:  Output: 

PC-send(m)pjir  m  G  [MConstc]  IC-send(u)Pq.  u  G  set c 

grant (u)p,  u  G  setc 


States: 

buffer ,  a  multiset  of  elements  of  [ MConstc L  initially  empty 
shared-key  G  [KConstc]  U  {X},  initially  X 

Transitions: 


PC-scnd(m)ptq 
Effect : 

arid  m  to  buffer 

JC-send(u)Pyq 
Precondition: 
m  is  in  buffer 
shared-key  ^  X 
v  =  enc  (m ,  shared-key) 

Effect: 

remove  one  copy  of  m  from  buffer 


grant {u)p 
Effect: 

if  u  G  [K Const c]  then 
shared-key  :=  u 


More-or-less  symmetrically,  we  have: 

Dec(C,  P)r,q-  where  p,q  6  P,  p  ^  q  : 

Signature: 

Input:  Output: 

IC-receive(v)p,q,  u  G  setc  PC-receive  (u)Ptq,  u  G  setc 

grant (u)q,  u  G  setc 


States: 


19 


buffer .  a  multiset  of  elements  of  set-cpM”),  initially  empty 
shared-key  E  [KConstc]  U  { _L},  initially  _L 

Transitions: 

/C- recent  (?/)P;9 
Effect: 

if  u  E  se*c(“A/”)  then 
add  u  to  buffer 

P  C-  rece  ive  ( u )  p ,  q 
Precondition: 
m  is  in  buffer 
shared-key  7^  X 
w  =  c/ec(m,  shared-key) 

Effect: 

remove  one  copy  of  m  from  buffer 

A. 6  The  Complete  Implementation 

I11  the  rest  of  this  section,  we  assume:  U  =  setc\  M  —  [MConstc]\  A  =  [AConsfc];  A  =  M  U  A;  Uf  is  an 
arbitrary  set  with  A  C  P7;  A'  is  an  arbitrary  set,  disjoint  from  A. 

The  implementation  consists  of  encoder  and  decoder  components,  an  insecure  channel,  eavesdropper  and 
environment,  plus  a  key  distribution  service.  More  precisely,  the  implementation,  PCImpli  (C,  P,  A,  U\  A1), 
is  obtained  by  composing  the  following  automata  and  then  hiding  certain  actions. 

•  Enc(C<  P)Ptq,  Dec(C ,  P)Ptq%  p,  q  G  P,  p  /  q. 

•  7C(P,P,A),  Eve(C,  P>  A),  Env{U,A,N ). 

•  KD(U*,  P,  A’,  -4'),  a  key  distribution  service. 

In  this  system,  the  eavesdropper  Eve  does  not  acquire  any  information  directly  from  the  KD  component. 

To  get  PChnpli  (C,  P,  A ,  [/',  .4'),  we  hide  the  following  actions  in  the  composition  just  defined:  eavesdrop pqa, 
pt  q  e  P,  a  e  A ;  IC-sendPtq ,  I C- receive p>g,  p,q  e  P;  grant p ,  p  G  P;  learna ,  a  G  -4;  reveala,  a  G  A'. 

A. 7  Correctness  of  the  Private  Communication  Implementation 

To  prove  correctness  of  PCImpli ,  we  demonstrate  an  implementation  relationship  between  PCImpli  and 
PC'.  The  invariant  and  implementation  proofs  presented  here  are  similar  to  [Lyn99].  The  proofs  have  been 
modified  to  mirror  the  Isabelle  proofs.  In  particular,  instead  of  a  simulation  relation  we  use  a  weak  refinement 
mapping  between  the  states  of  PCImpli  and  PC. 

A.  7.1  Invariants 

Invariant  A. 5.  In  all  reachable  states  of  PCImpli ,  the  following  are  true: 

1 .  If  EncP)q. shared-key  ^  _L  then  EncP)q. shared-key  —  I\D. chosen-key. 

2.  If  Decp  ^.shared-key  /  _L  then  DecPiq.  shared-key  —  KD. chosen-key. 

Proof.  We  prove  this  by  induction  on  the  length  of  an  execution. 

Basis:  Both  claims  are  true  in  the  initial  state  because  Encpq,  shared-key  and  Decp>q. shared-key  are  both 

1. 

Inductive  step:  Consider  a  step  (s,  a,  s')  of  the  implementation,  where  s  satisfies  the  invariant. 


grant  {u)q 
Effect: 

if  u  E  [KConstc]  then 

shared-key  u 
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l.o  =  chaos  e-key 

By  the  precondition  on  a  and  the  inductive  hypothesis,  I\D. chosen-key  =  Encp%q. shared-key  =  DecP}q. shared-key 
_L  in  s.  Therefore,  Encp  q. shared-key  =  Decp shared-key  =  _L  in  s' . 

2.  q  =  grant (u)P  By  the  precondition  on  o ,  I\D. chosen-key  =  Encpq.  shared-key  — 

Dec p>q. shared-key  =  u  in  .s'. 

In  other  cases,  the  invariant  is  trivially  preserved. 

□ 


Invariant  A. 6.  In  all  reachable  states  of  PCImpl j .  the  following  are  true: 

1.  If  Encp  q. shared-key  =  _L  then  I C. buffer  (p.  q)  is  empty . 

2.  If  Encp  q. shared-key  =  JL  then  Decp,q.  buffer  is  empty. 

Proof  By  induction.  For  the  base  case,  both  parts  of  the  claim  are  true  in  the  initial  state,  channel  and 
decoder  buffers  are  empty. 

For  the  inductive  step,  consider  a  step  (s,a,s;)  of  PCImpl  1 ,  where  s  satisfies  the  invariant.  There  are 
two  non-trivial  cases  that  add  elements  to  channel  or  decoder  buffers: 

1.  q  =  IC-send(u)}^g 

The  precondition  of  this  action  ensures  that  EncPy(i. shared-key  /  _L,  so  this  step  cannot  violate  part  1 
of  the  invariant.  Part  2  is  trivially  preserved. 

2.  q  =  IC-receive(u)p%q 

If  Erie  pq.  shared-key  =  _L,  then  by  the  inductive  hypothesis  IC. buffer (p ,  q)  is  empty,  so  this  step  cannot 
be  enabled,  and  therefore  cannot  violate  part  2  of  the  invariant.  Part,  1  is  trivially  preserved. 


□ 

Invariant  A. 7,  In  all  reachable  states  of  PCImpl j  the  following  holds:  for  all  p,  q  E  P,  and  all  u  E  N,  u 
fi  I C.  buffer  (p,  q). 

Proof  By  induction.  For  the  base  case,  the  claim  is  trivially  true  in  the  initial  state,  since  IC  .buffer(p,  q)  is 
empty. 

For  the  inductive  step,  consider  a  step  (s,a  ,  s')  of  PCImpl i,  where  s  satisfies  the  invariant  .  The  only 
non-trivial  case  is  a  =  IC-$end(u)P}q,  where  u  =  enc(m,k). 

The  precondition  and  type  considerations  imply  that  m  E  [MConstc]  and  k  E  [KConstc].  So  m  Pi 
Af  Const c  -f-  0;  let  mf  be  any  element  in  m  H  MConstc .  Similarly,  k  C\  KConstc  i=-  0;  let.  k'  be  any  element  in 
k  fi  KConstc.  Then  enc(m' ,  kf)  E  u- 

Suppose  that  u  E  [MConstc].  Then  u  fl  MConstc  ^  0  so  let  id  be  any  element  in  u  fl  MConstc.  Then 
[enc(mf ,  Ar')]  =  it  =  [u'].  But  Lemma  A. 2  implies  that  enc(m',  k')  and  id  are  not  equivalent  terms,  because 
the  difference  between  the  number  of  enc  and  dec  operators  in  the  first,  of  these  is  1  and  the  difference  in  the 
second  of  these  is  0.  It.  follows  that  u  fi  [MConstc].  which  implies  that  this  event  does  not  add  an  element 
of  M  =  [ MConstc ]  to  the  channel  IC. 

By  an  identical  argument,  u  fi  [KConstc]. 

□ 


Invariant  A. 8.  In  all  reachable  states  of  PCImpl  j,  if  u  E  N  then  u  fi  Eve. has. 

Proof  By  induction.  For  the  base  case,  the  claim  is  trivially  true  in  the  initial  state,  since  Eve. has  is  empty. 

For  the  inductive  step,  consider  a  step  (s,a,  s')  of  PCImpl j,  where  s  satisfies  the  invariant.  There  are  * 
three  non-trivial  cases: 
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1.  a  —  eavesdrop (u)P}q, a 

This  action  cannot  add  an  element  of  N  to  Eve. has,  because  by  invariant  A. 7  there  are  no  elements  of 
N  in  IC. buffer  (p,q)  in  state  s. 

2.  a  —  learn (u) a 

The  precondition  of  this  action  ensures  that  u  $  A r. 

3.  a  =  compute (ti,  f)a 

By  the  inductive  hypothesis,  there  are  no  elements  of  N  in  s. Eve. has.  In  particular,  there  are  no  keys 
(of  type  A')  in  s. Eve, has.  So  this  action  cannot  be  enabled  in  s. 

□ 


We  present  the  Isabelle  proof  of  invariant  A. 8. 


Goal  M invariant  PCImpl_ioa  lemmaA_6"; 

(*  Apply  simplification  tactic  to  reduce  the  goal  to  (non-trivial)  subgoals 
corresponding  to  automata  actions 

*) 

by  (simplif y_inv_goal_tac  lemmaA_6_def  1); 

(*  There  are  three  cases  still  left  to  show:  eavesdrop,  learn,  and  compute.  *) 


(*  eavesdrop  *) 

(*  Strip  outer  quantifiers  and  implications,  flatten  conjunctions 
in  hypotheses  *) 

by  (REPEAT  (rtac  alii  1  ORELSE  rtac  impl  1  ORELSE  etac  conjE  1)); 
by  (rename_tac  Ms  t  u  p  q"  1); 


(*  Apply  invariant  lemma  A. 5  *) 
by  (apply_inv_tac  lemmaA_5  lemmaA_5_def  1); 


(*  The  rest  is  definition  expansion,  quantifier  instantiation, 
and  simplification  *) 
sf  [Ball.def]  1; 
by  (strip_tac  1); 


by  (thin_tac  "ALL 
by  (eres_inst_tac 
by  (eres_inst_tac 
by  (eres_inst_tac 

by  (case_tac  "x  = 
sf  □  1; 
ba  1; 


X. 

x  : 

N_set 

—  >  5 

: 

[(’ 

ivi< 

A  > 

i _ i 

allE 

1) 

[(• 

•x", 

"q")] 

allE 

1) 

[(' 

'X", 

”x")] 

allE 

1) 

u" 

i); 

eve  s"  1); 


(*  learn  *) 

(*  Solved  automatically  by  Isabelle  *) 
by  (Blast_tac  1); 


(*  compute  *) 
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(*  Solved  automatically  by  Isabelle  after  expanding  some  definitions  *) 
by  (asm_f ull_simp_tac  (simpset()  addsimps  [N_set_def ] )  1); 
by  (Blast_tac  1); 

(*  done  *) 
qed  "lemmaA_6M; 


High-level  tactic  simplif  y_inv_goal_tac  takes  care  of  breaking  clown  the  invariant  definition,  applying 
the  Isabelle  induction  tactic,  and  simplifying  the  resulting  cases.  In  the  example  invariant  proof  shown  here, 
the  user  is  left  with  the  same  three  non-trivia!  cases  that  were  considered  in  the  hand  proof.  The  tactic 
apply _inv_tac  is  another  instance  where  a  high-level  step  in  the  hand  proof  can  be  simulated  effectively  by 
a  high-level  Isabelle  tactic.  In  the  example  proof  for  the  case  a  =  eavesdrop(u)P^^a,  apply_inv_tac  applies 
the  invariant  A. 7  to  state  s  and  adds  the  result  to  the  list  of  assumptions  in  the  current  goal,  to  be  used 
later  in  the  proof. 

A. 7. 2  Implementation  Proof 

We  show  that  PC  Imp!  j  implements  PC  by  exhibiting  a  weak  refinement  mapping  F  from  the  states  of 
PCImplj  to  the  states  of  PC.  F(s)  is  the  multiset  union  of  three  multisets,  Ai,  Ao,  and  A3,  where: 

1.  A 1  =  s.Encpq.  buffer. 

2.  A o  =  dec(sJC.buffer(p ,  q).  s.KD. chosen-key)  if  s. I\D. chosen-key  /  T  else  0. 

3.  A3  =  dec(s.Decp<q. buffer,  s.KD. chosen-key)  if  s.KD. chosen-key  ^  _L  else  0. 

Thus,  the  multiset  of  messages  in  transit  at  the  specification  level  is  obtained  by  combining  the  multisets  of 
messages  at  the  encoder  and  the  decoder  and  the  multiset  of  messages  in  the  insecure  channel.  The  messages 
in  the  insecure  channel  and  decoder  buffers  must  be  decoded  with  the  shared  key  to  get  the  correspondence. 

Theorem  A. 9.  F  is  a  iveak  refinement  mapping. 

Proof.  The  proof  proceeds  by  induction. 

Base:  Easy  -  in  the  start,  states  of  PC  and  PCImplj  all  the  multisets  are  empty. 

Inductive  step:  Consider  (s,  7r,  s')  in  the  implementation,  where  s  is  a  reachable  state.  The  interesting  cases 
are: 

1.  7 r  —  IC-send{u)p}q,  where  u  —  enc\m,k) 

This  corresponds  to  the  trivial  one-state  execution  fragment  F(s)  of  PC(U,  P)  M,  A).  We  must  argue 
that  F(sf)  =  F(s).  It  follows  from  invariant  A. 5  and  the  precondition  that  this  action  is  enabled  only 
if  s.KD  .chosen-key  /  X.  So  this  event  removes  ???  from  Encrq. buffer  (and  from  Ai).  The  encoded 
version  u  of  m  is  added  to  the  insecure  channel,  and  from  the  equations  relating  enc  and  dec  functions 
it  follows  that  m  is  added  to  Ao.  So  the  multiset  F(s')  is  the  same  as  F(s). 

2.  7r  —  IC-receive{u)p>q 

The  argument  is  similar  to  the  case  7r  =  lC-send\u)pq .  The  key  point  is  that  u  is  accepted  by  dec , 
because  it  is  of  type  “i\F\  This  follows  from  the  precondition  in  the  insecure  channel  and  uses  an 
invariant  saying  that  all  the  elements  of  IC '.buffer p  q  are  always  of  type  aM'\  (This  invariant  was 
omitted  in  the  description  above,  but  has  been  proven  in  Isabelle). 

3.  7r  —  PC-receive(u)p,q 

This  corresponds  to  the  same  action  in  PC.  In  this  step,  u  =  dec(m,  s.KD , chosen-key)  for  some 
m  £  s. Dec v  q. buffer  by  invariant  A. 5.  Thus,  u  £  F(s). buffer (p,q ),  which  means  that  n  is  enabled  in 
the  specification  automaton,  in  state  F(s). 
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It  remains  to  show  that  after  executing  i r  in  state  F(s)}  PC  must  be  in  state  F(s').  One  copy  of  m 
is  removed  from  s.Deep^q. buffer  (and  therefore  from  A3)  while  a  copy  of  u  is  removed  from  the  ab¬ 
stract  channel  F(s).buffer(p,  q).  Since  u  =  dec{m,  s.KD. chosen-key),  this  preserves  the  correspondence 
between  the  multisets. 

4  tj.  —  reveal (u) a 

This  corresponds  to  reveal(u)a  in  the  specification  PC.  We  must  show  that  u  £  M.  The  precondition 
for  reveal(u)a  (in  Eve)  implies  that  u  E  s. Eve  .has.  Invariant  A. 8  implies  that  u  ^  AT ,  which  implies 
that  u  (£  M . 

5.  7 r  =  choose -key 

This  corresponds  to  the  trivial  one-state  execution  fragment  F(s)  of  PC(U,P,M,A).  From  the  pre¬ 
condition,  we  have  s.KD .chosen-key  =  _L.  It  follows  from  invariants  A. 5  and  A. 6  that  the  insecure 
channel  and  decoder  buffers  are  empty  in  s.  Therefore,  this  action  has  no  effect  on  the  multisets  of  the 
mapping  F. 

□ 

Theorem  A. 10.  PCImpC  (C,  P ,  A,  U1,  A')  A  PC(U,  P ,  M,  A). 

Proof.  Follows  from  Theorems  A. 9  and  2.1.  ^ 

B  Diffie- Heilman  Key  Distribution  Implementation 

This  section  describes  the  Diffie-Hellman  key  distribution  protocol.  Throughout  the  section,  we  assume  C  is 
an  augmented  base-exponent,  cryptosystem,  P  —  {pl,p2},  and  A  is  a  nonempty  set. 


B.l  The  Endpoint  Automata 

We  define  two  symmetric  automata,  for  the  two  elements  of  P. 
DH(C.,P)p  1: 

Signature: 

Input:  Internal: 

IC-receive(b)P2lPi  ♦  b  E  setc(“B”)  choose-exPpl 

Output: 

IC-send(b)pi,p2 ,  b  E  setc(uB ”) 
grant(b)pi,  b  E  $etc(uB”) 


States: 

chosen-exp  E  [XConstl  c]  U  { _L} T  initially  _L 
base-sent .  a  Boolean,  initially  false 
rcvd-base  E  sefc(“B”)  U  {X},  initially  X 
granted ,  a  Boolean,  initially /a/se 

Derived  variables: 

chosen-base  E  se/c(“£?')  U  {X},  given  by: 

if  chosen- exp  ^  X  then  erp([60c],  chosen-exp)  else  X 


Transitions: 
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choose- exp  pi 

Precondition: 

chosen- exp  —  X 
Effect: 

chosen-exp  choose  x 
where  x  E  [XConstl  c^] 

IC-scnd(b)pltPo 

Precondition: 

chosen-exp  ^  _L 
b  =  chosen-hase 
base -sent  =  false 
Effect.: 

base-sent  :=  true 


IC-receive(b)p2,pi 

Effect: 

revd-base  :=  b 

grant {b)pi 

Precondition: 

chosen-exp  7^  X 
revd-base  7^  X 

b  =  exp ( revd-base  ,  ch osen-exp  ) 
granted  =  false 
Effect: 

granted  :=  true 


The  automaton  for  p2  is  the  same,  but.  interchanges  uses  of  pi  and  p2,  and  likewise  of  XConstl  and 
X  Const  2. 

DII{C,  P)P2‘ 

Signature: 

Input:  Internal: 

IC-receive  (b)pitp2t  b  E  setc{iiB'' )  choose-exp  p  2 

Output: 

IC-send[b)p2tpi ,  6  E 
flfran/(6)p2»  &  €  sef^pTT*) 


States: 

chosen-exp  E  [A'Con.sf^c]  U  {X},  initially  X 
base-sent ,  a  Boolean,  initially  /a/se 
revd-base  E  U  {X )-,  initially  X 

granted ,  a  Boolean,  initially  /a/se 

Derived  variables: 

c/iosen-6a.$f  E  U  {X},  given  by: 

if  chosen-exp  7^  X  then  exp  ( [60^],  chosen -e: vp )  else  X 


Transitions: 

choose-exp  p2 
Precondition: 

chosen- exp  —  X 
Effect: 

chosen- exp  choose  x 
where  x  E  [A  Cons  t2c] 

JC-send(b)p2rPi 

Precondition: 

chosen- exp  7^  X 
b  =  chosen-base 
base -sent  =  false 
Effect: 

base- sent  :=  true 


IC- receive  (b)pi,P2 
Effect: 

revd-base  :=  6 

grant  (b)p2 

Precondition: 

chosen-exp  7^  X 
revd-base  7^  X 

6  =  exp  ( revd-base  ,  chosen-exp ) 
qranted  =  fa/se 
Effect: 

granted  true 


B.2  The  Complete  Implementation 

In  the  rest  of  this  section,  we  assume:  U*  —  setc\  I\f  =  A’7  =  [XConstl c]  U  [XCon$t2c\,  Ar/  —  K'DX1 . 

The  implementation  consists  of  two  endpoint  automata,  an  insecure  channel,  an  eavesdropper  and  an 
environment.  Specifically,  implementation  KDImpl(C,  P,  A)  is  the  composition  of  the  following  automata, 
with  certain  actions  hidden: 
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•  DH(C ,  P)p,  p  €  P,  endpoint  automata. 

•  IC(U',P,A),  Eve(C,  P,  A),  Env(U'yA,N'). 

To  get  I\DImpl(C,  P,  A),  we  hide:  eavesdrop ptq}(l,  p,q  £  P,  P  7^  h  a  £  A;  IC-send Piq ,  IC-receivep >q,  p,q  G  Pi 
p^  q\  learn a ,  aE  A. 


B.3  Invariants 

I11  the  system  KDImpl ,  we  use  Df/(p)  for  p  €  P,  IC,  and  Eve  as  handles  to  help  in  naming  state  variables 
in  the  composed  state.  The  first  invariant  says  that  messages  that  have  been  received  or  are  in  transit  are 
correct: 

Invariant  B.l.  In  all  reachable  states  of  KDImpl ,  the  following  are  true: 

1.  If  DH  (p) .  rcvd-base  ±  Landq^p  then  DH(q).  chosen-exp  £  1.  and  DH  (p)  .rcvd-base  =  DH  (q)  .chosen-base . 

2.  If  u  e  IC .buffer (p,q),  then  DH(p). chosen-exp  1.  and  u  —  DH (p) .chosen-base . 

Remark:  There  was  a  typo  in  part  1  of  invariant  B.l  as  stated  in  [Lyn99].  Client  names  p  and  q  were 
reversed  in  the  conclusion,  which  read  DH (q) .rcvd-base  =  DH (p) .chosen-base  instead  of  DH (p) .rcvd-base  = 
DH(q) .  chosen-base . 

The  next  two  invariants  say  that  no  N1  elements  ever  appear  in  Eve. has  or  in  the  insecure  channel. 

Invariant  B.2.  In  all  reachable  states  of  KDImpl,  for  allp,  q  G  P,  p  ^  q,  and  all  u  G  N' ,  u  IC.bujfer(p,  q). 

Proof.  Analogous  to  the  proof  of  invariant  A. 7.  Base:  The  claim  is  true  initially,  because  the  channels  are 
empty. 

Inductive  step:  Consider  a  step  (s,  7r,  s')  of  the  implementation,  where  s  satisfies  the  invariant.  The  interesting 
case  is: 

1.  lC-s€nd\b)v,q 

b  is  an  equivalence  class  of  a  singly-exponentiated  base  60,  and  thus  cannot  be  a  member  of  A7  (a  set  of 
non-exponentiated  constants)  or  a  member  of  K!  (a  set  of  doubly-exponentiated  bases)  by  Lemma  A. 4. 
Thus,  this  action  cannot  add  a  member  of  Nf  to  1C  .buffer  [p,q). 

□ 


Invariant  B.3.  In  all  reachable  states  of  KDImpl,  if  u  G  Nf  then  u.  Eve. has. 

Proof.  Analogous  to  the  proof  of  invariant  A. 8.  Base:  The  claim  is  true  initially,  because  Eve. has  is  empty. 
Inductive  step:  Consider  a  step  (s,  7T,  s')  of  the  implementation,  where  s  satisfies  the  invariant.  The  interesting 
cases  are: 

1.  eavesdrop  (it)  1?jqia 

Applying  invariant  B.2  to  state  s,  it  follows  that  u  cannot  be  a  member  of  N'. 

2.  learn  (u) a 

We  use  the  precondition  in  Env. 

3.  compute (u,  f) a  • 

The  only  function  in  the  cryptosystem  is  exp.  This  can’t  produce  any  elements  of  [XConstl]  or 
[XConst2]  because  of  type  considerations.  Moreover,  in  order  to  produce  an  element  of  [B2]y  an 
element  of  [XConstl]  U  [X Const 2]  is  needed. 

□ 
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B.4  Implementation  Proof 

We  show  that  I\DImpl(C.  P,  -4)  implements  I\D(U,  P ,  A’,  .4)  using  a  refinement  mapping.  The  mapping  F  is 
defined  as  follows: 

1.  If  s .DH (p) .chosen-exp  /  _L  for  all  p  £  P,  then  F(s). chosen-key  — 

cxp(s.DIi(p] ). chosen-base ,  s.DH(p'2). chosen-exp),  and  otherwise  F(s). chosen-key  =  J_. 

2.  F (s) .notified  =  {p  £  P  :  s.DP(p).#/t/»Ay/}. 

Theorem  B.4.  P  /.§  u  refinement  mapping . 

Proof  By  induction, 

Po.se;  Easy. 

Inductive  step:  Consider  (s,  7T,  .s')  and  f  and  consider  cases.  The  most  interesting  cases  are: 

1.  7T  =  choose  -exp  . 

If  s.DH (q) .chosen-exp  —  _L,  where  q  /  p  then  this  maps  to  the  trivial  one-state  execution  fragment 
P(.s).  The  correspondence  is  trivially  preserved.  Otherwise,  this  corresponds  to  a  one-action  move 
choose-key ,  with  a  chosen  value  of 
e.rp ( s' . DP  ( q ) .  ch osen- base ,  .s' . DP (p) .  chose »-erp ) . 

Enabling  is  straightforward,  as  is  the  preservation  of  the  refinement. 

2.  n  =  IC-send(b)pq. 

This  corresponds  to  the  trivial  one-state  execution  fragment  F(s).  It  is  easy  to  see  that  F(sf)  =  F(s). 

3.  7 r  =  IC-receive(b)p  q 

This  corresponds  to  the  trivial  one-state  execution  fragment  F(s).  It  is  easy  to  see  that  F(s')  =  F(s). 

4.  7 r  =  grant (b)p 

This  corresponds  to  a  one-action  move  grant (b)p  in  I\D.  The  interesting  fact  to  show  here  is  the 

enabling,  specifically,  that  the  value  b  =  exp(s.DH(p).rcvd-base,  s.DH(p). chosen-exp)  is  equal  to 

F (s). chosen-key .  Invariant  B.l  implies  that 

b  —  exp(s .DH (q) .chosen-base ,  s . DH (p) .chosen-exp) . 

and  equations  in  the  cryptosystem  imply  that  this  is  equal  to 

exp(exp([bO\,  s.DH (pi). chosen-exp),  s.DH(p2). chosen-exp).  The  definition  of  F  says  that  this  is  equal 
to  F (s). chosen-key ,  as  needed. 

5.  7 r  =  eavesdrop 

Corresponds  to  trivial  fragment.  Easy  to  see  correspondence  preserved. 

6.  7r  —  compute 

Corresponds  to  trivial  fragment.  Easy  to  see  correspondence  preserved. 

7.  7T  =  learn (u) a 

Corresponds  to  trivial  fragment.  Easy  to  see  correspondence  preserved. 

8.  7 r  =  reveal (u) a 

This  corresponds  to  a  one-action  move  reveal (u)a  in  I\D .  We  must  show  that  u  £  Kf .  The  precondition 
for  reveal (u) a  (in  Eve)  implies  that  u  £  s. Eve. has.  Invariant  B.3  implies  that  u  ^  N\  which  implies 
that  u  I\f . 


□ 


□ 


Theorem  B.5.  KDImpl(C}  P,  A)  ^  I\D(U ,  P ,  A’,  .4). 
Proof  By  Theorems  B.4  and  2.1. 
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C  Combining  Diffie-Hellman  Key  Distribution  with  Private  Com¬ 
munication 

Now  we  are  read}'  to  combine  the  Diffie-Hellman  key  distribution  implementation  with  the  rest  of  the  private 
communication  protocol.  The  new  private  communication  protocol  is  identical  to  PCImplj ,  with  one  change: 
the  key  distribution  specification  KD  is  replaced  by  Diffie-Hellman  key  distribution.  As  we  said  earlier,  we 
assume  that  the  key  distribution  protocol  and  the  private  communication  protocol  have  separate  insecure 
channels  and  eavesdroppers,  and  the  eavesdroppers  do  not  communicate  with  each  other. 

Let  C  be  a  shared-key  cryptosystem  and  £  a  base-exponent,  cryptosystem.  In  this  section,  we  assume:  U  — 

setc:  M  =  [MConst\c;  K  -  [[B£]e]ci  N  =  M  U  A’;  Uf  =  sets]  K'  =  [B*2e]\  X'  =  [X  Const  l]s  U  [XConstS]e\ 

N*  =  Kf  UA;  P  —  {/>l,p2};  A  is  a  nonempty  set;  Af  is  an  arbitrary  set,  disjoint  from  A.  Note  that  the  key 
set  K  of  cryptosystem  C  consists  of  doubly-exponentiated  bases  of  cryptosystem  £. 

As  before,  the  implementation  consists  of  encoder  and  decoder  components,  an  insecure  channel,  eaves¬ 
dropper  and  environment,  plus  a  key  distribution  module.  More  precisely,  the  implementation,  PCImpl2{C ,  £,  P,  A ,  A '), 
is  obtained  by  composing  the  following  automata  and  then  hiding  certain  actions: 

•  Enc(C ,  P)M,  Dec(C ,  P)Ptq>  P,q  €  P>P  7^  (l • 

•  JC(P,P,A),  Pue(C,P,A),  Pnu(P,A,  A'). 

•  KDImpl(S,  P,A'),  the  key  distribution  module. 

In  this  system,  the  eavesdropper  Eve  does  not  acquire  any  information  directly  from  the  KDImpl  component, 
and  conversely,  the  eavesdropper  inside  KDImpl  cannot  receive  information  from  outside  KDImpl. 

To  get  PCImpl2(C,  £,  P,  A,  A1),  we  hide  the  following  actions  in  the  composition  just  defined:  eavesdrop  pqa, 
p,  q  £  P,  a£  A;  IC-sendp>q ,  IC-receiv€p>q ,  pyq  £  P;  grant p ,  p  £  P;  leama ,  a  G  A;  reveal a,  a  £  A'. 

Theorem  C.l.  PCImplo  {C ,  £ ,  P,  A,  A;)  ^  PC(P,  P,  M,  A) . 

Proof.  From  theorem  B.5  we  have  KDImpl  (£y  P,  A')  ^  P,  A,  A').  The  only  difference  between 

PClmplo  and  PCImpl ±  is  that  we  have  substituted  KDImpl  (£  y  P,  A7)  for  KD(U'y  P,  A",  A').  So  by  the  com- 
positionality  theorem  2.2,  PCImphlC,  £y  P,  A,  A')  ^  PCImpl i  (Cy  P,  A,  U'y  A').  The  result  then  follows  by 
theorem  A.  10  and  transitivity  of  D 
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